Cantata完成单元测试、集成测试或代码覆盖率采集后，可以把测试结果整理成HTML、XML等报告，也可以保留用于后续分析的测试结果文件。报告里是否带有覆盖率，不只看测试有没有执行，还要看本次测试是否做了覆盖率插桩、运行后有没有生成覆盖数据，以及报告读取的是哪一批结果。遇到功能测试结果正常、覆盖率章节却为空的情况，可以先从结果文件和覆盖数据入手，再检查报告使用的数据范围。

Cantata里的测试用例通常保存在C/C++测试脚本中，批量测试数据还可以使用表驱动测试方式管理。这里要分清两种情况：如果已有的是CSV格式的输入值、预期结果等测试数据，可以导入现有表驱动测试；如果已有的是另一套Cantata工程里的完整测试脚本，更适合把对应Test Script及关联文件迁到当前测试工程。测试用例导入失败时，问题经常出在CSV字段和函数接口对不上、测试脚本版本变化，或者原有Stub、全局数据已经和当前源码不一致。

Cantata执行单元测试或集成测试后，可以继续查看代码被测试用例实际执行到什么程度。覆盖率结果并不只有一个百分比，还会按语句、判定、条件、MC/DC等不同指标分别统计。测试已经运行成功，但覆盖率里少了某些函数、某些源码文件没有数据，或者多个测试脚本的结果没有合在一起时，先分清是代码没有执行到、插桩范围缺失，还是当前查看的覆盖数据没有选全，处理起来会清楚很多。

Cantata做C/C++单元测试时，被测函数经常会调用硬件驱动、通信接口、操作系统函数或其他尚未纳入测试范围的模块。直接把这些真实依赖一起编进测试程序，测试环境会变得很难控制。Cantata可以用Stub模拟外部调用，也可以用Wrapper截获真实函数调用，在测试用例里指定返回值、检查传入参数和控制不同调用次数对应的行为。测试桩已经生成却出现返回值不对、调用次数不匹配或测试程序仍进入真实函数时，可以从桩类型、调用实例和接口定义几个位置查起。

Cantata开始做C/C++单元测试前，要先把被测源码、原项目构建参数和测试使用的编译环境接起来。工程创建后能看到源码，并不代表测试环境已经配置好，头文件路径、预处理宏、编译器选项或目标Deployment少一项，后面生成测试脚本时就可能报解析错误，构建测试程序时也容易停下来。Cantata提供Testing Project向导，可从CMake、Make、IAR、Keil、Visual Studio等构建环境读取工程信息，配置出错时可以沿着源码位置、Build System和编译参数逐项检查。

MC/DC关注复合判定中的每个基本条件，能否在其他条件保持适当状态时独立改变最终结果。处理“Cantata MC/DC覆盖率怎么统计Cantata MC/DC覆盖缺口如何定位”时，要先启用正确的覆盖规则，再从未满足的条件组合反推测试数据，不能只看一个总百分比。覆盖率达到目标后，仍要结合需求测试和异常场景判断测试是否充分。

Cantata测试脚本可以在主机环境中编写，再使用目标编译器构建为适配目标板的测试程序。真正影响执行成败的环节不只是脚本本身，还包括部署库、下载方式、启动命令和结果回传通道。处理Cantata怎么执行目标板测试Cantata目标板测试结果回传失败如何排查，需要把构建、下载、运行和结果收集拆开检查。

Cantata AutoTest可以从C/C++源代码中分析可执行路径，并按照选定的结构覆盖目标自动生成测试脚本和测试向量。处理“Cantata AutoTest怎么生成测试用例Cantata AutoTest生成的用例覆盖率不足是什么原因”时，不能只看生成了多少条用例，还要确认源码模型、覆盖规则、函数调用控制和测试运行环境是否完整，否则用例能够执行，覆盖率仍可能停在目标值以下。

Cantata进行C/C++单元测试时，桩函数不仅用来替代外部依赖，还能模拟返回值、修改输出参数、注入异常，并记录被测函数的实际调用过程。围绕“Cantata桩函数怎么配置Cantata桩函数调用顺序如何校验”开展测试时，需要先明确隔离边界，再为不同调用次数建立独立实例，否则测试结果很容易与真实执行路径对不上。

使用Cantata做C/C++单元测试时，工具可以先生成测试框架，但测试能否真正验证需求，仍取决于输入数据和预期结果是否合理。处理Cantata测试脚本怎么生成Cantata测试脚本中的输入和预期结果怎么填写，需要先明确被测函数的参数、全局变量、返回值和外部调用，再把每个测试场景拆成可重复执行的数据组合。